8.2 リリース計画

AoAD2eとの重なり

いつでもリリースできるようにする

8.2.1 一度に1つのプロジェクト

図 8-1 (Figure. Effects of multitasking on value)

1つずつプロジェクトをリリース

価値が高いプロジェクトからリリースすることで投資対効果が高まる

他のプロジェクトに取り組んでいる間に収入が得られるため

8.2.2 早期にリリース、頻繁にリリース

図 8-2 (Figure. Effect of Frequent Releases on Value)

1プロジェクトだがリリース複数回

最も価値のある機能に最初に取り組みリリース

他の機能に取り組んでいる間、収入が得られる

図で伝えたいことは変わっていないと認識した

プログラマにとってのメリット

XP の秘訣の 1 つは、難しいことを頻繁に少しずつやることで、たいていのリスクとほぼすべての悩みの種を取り除くということだ。(p.221)

8.2.3 頻繁にリリースする方法

各リリースに含める機能を減らして、もっと頻繁にリリースしよう。（p.221）

8.2.5 計画を適応させる

各リリースの後にステークホルダーのフィードバックを集めて、重要でないとわかった機能に取り組むことをやめて、ステークホルダーが最も価値があると思う機能にもっと取り組めばよい。(p.223)

学んだことを計画に反映

計画を適応させてチャンスを作り出し、チャンスを利用する

8.2.6 選択肢をオープンにしておく

作り出したチャンスを最大に活かすために、いつでもリリースできるようにしておく

単独で意味を成すストーリー

それぞれのストーリーはそれ 自身でリリース可能にしておくべき (p.224)

リリース可能なストーリーを作ると、計画にもっと柔軟性を持たせることができる。(p.225)

図 8-3 (Figure. Horizontal and vertical stripes)

（なにもないより半分のインクリメントのほうが価値があるのでリリースして方向転換、が書かれている）

横スライス：ステップごとに作ったストーリー

すべて完了しないと、ソフトウェアをリリースしたり、効果的なレビューができなくなる。(p.224)

計画の柔軟性がなくなる（Adaptive、ひいてはAgileでなくなる）

全ステップやるかやらないかになっている。途中でリリースできない

縦スライス：価値を限定的にし個別にリリースできるように分けたストーリー

全部で 3 つのタスクだが、もっと限定的で個別に役立つものを提供するような ストーリーを作る (p.224)

8.2.7 リリース計画の作り方

機能（スコープ）で区切るか、タイムボックスで区切るか

たいていの場合、タイムボックスによる計画の方がよい。(p.225)

8.2.8 最終責任時点で計画する

イベントが先であればあるほどほど、リリース計画に詳細を含める必要がない (p.227)

段階的な計画期間

図 8-5 （不確実性コーンっぽい図）

コラム：適応型の旅行＝最終責任時点で計画

最終責任時点まで細部を残した

選択肢を残すようにパスを用意している！

予想もしなかったようなチャンス（ソフトウェア開発でも同じ）